POCUHEH? BBSUttS 



Bp) Its 367 

AUTHOR 
TITLE 



INSTITUTION 
SPONS IGSNCI 



REPOST NO 
i?Ue BATE 
NOTE 



EDES PRICE 
DESCRIPTORS 



IDENTIFIERS 



ABSTRACT 



SE 019 897 

Goldstein,* Ira P» • 

5ua«a'ry of HYCROPII: a System for Understanding Simple 
E^cture Programs, artificial Intelligence Hemo' Number 
305. / ' . . ' v' , . 

Hassachusetts Inst^of Tech., Cambridge. Artificial 
Intelligence Lab* 

Advanced Eesfiarch Pro jects Agency (DOD) ,- Washington, 
D.C. J National science Foundation, Washington^ 
D.C. . . * . ' / » ' 

lOGo-te 

May 7«J 

63p. ; For related documents, see SD 077 236, 240*243, 
SF 01^ 893-894, -and 896-900 ^ ■ 

MF-$0^83 HC-$3i50 Plus Postage ^ ' 

♦Computer Assisted Instruction; *Computer Graphics; 
♦Educational Research; *Elementary Secondfiry 
Education; Instructional Materials; 

♦Photocomposition! Pictorial Stimu^li; Science • . 
Education ,\ 
Bes ear ch Reports ' ^ 



^ This oeport describes the operation of « computer ( 
monitor called MYCE0F7, a system which can debug elementary programs 
for drawing pictures. The basic skills which are funda,mental to ^ . 
debugging skill (description, plan, linearity, insertions, global ' » 
knowledge, and imperative semantics) are examined. These programs are * 
written for LOGO turtles. (Author/CP) . ' 



* Documents acguired by EBIC include many informal unpublished * 

* materials not available from other sources. ERIC makes :every^ effort 

* to obtain the best copy available. Nevertheless^ items of marginal * 

* reproducibility are oft^n encountered and thi^ affects the quality 

* of the microfiche and hardcopy re prqductiotis BRIO makes Available * 

* via the ERIC Document Heproductian Service (EDES). 6drs is not * 

* responsible for the quality of th!e original document. Reproductions * 

* supplied by SDR S are the best^ tha^l: can be made from the original. * 

)ft :|e :te :te :te :i|c 9|i 3|i 9«e 9«e 9«e 9«( 9«e sfe 9«e sfe sfe sfe sfe sfe :«{ sfe sfe sfe a|t 9^ 



U .S. OCPAKTMCNTOF He*tTH. 
EDUCATION ft WELFARE 
NATIONAL INSTITUTE OF 
EDUCATION' 

THIS DOCUMENT HAS BEIEN "^REPRO- 
DUCED EXACTLY AS RECEIVED PROM 
THE PERSON OR ORGANIZATION ORIGIN- 
ATINGJT POINTS OF VIEW 0R/)PINI0NS 
STATED DO NOt NECESSARILY REPRE*- 
SENT OFFICIAL NATIONAL INSTITUTE OF 
EDUCATION POSITION OR PpLlCY 



MASSACHUSETTS I NST I TUTE OF TECHNOLOGY- 
ARTIFICIAL INTELLIGENCE LABORATORY 



A. I ♦ Memo '385 



tlay 1974 
Logo Memo 10 



SUMMARY OF flYLROFT: . . V 
A SYSTEM FOR UNDERSTANDING SIMPLE PICTURE PROGRAMS*. 

. Ira P. Goldatein 



ABSTRACT 



'PEnMlSGlON TO REPRODUCE THIS COPY- 
RIGHTED MATERIAL HAS BEEN GRANTED, BY 



I 

LobV Pfo/- 



ence. 



TO ERIC AND ORGANIZATIONS OPERATING 
UNDER AGREEMENTS WlTM THE NATIONAL IN- 
STITUTE OF EDUCATION FURTHER REPRO- 
DUCTION OUTSIDE THE HRIC SYSTEM RE- 
OUIREG PERMISSION OF THE COPYRIGHT 
OWNER • , 



''A collection of powerful Ideas— description, plans, linearity, 
insertions, global Knoi^iledge and imperative semantics— are explored 
which are fundamental to debugging skill* To make these concepts 
precise," a computer monitor called MYCflOFT.is described' that canr debug 
elementary programs for drawing pictures/ The programs are those 
written for LOGO turtles* 



*>KThe first section of this paper will appear in the Proceedings of the 
Conference on Artificial Intelligence and the Simulation of Behavior to 
be held at the University of Sussex, July 1974. 



This work was supported in part by the National Science Foundation under^ 
grant number GJ-1049 and condwcted at the Artificial Intelligence 
Laboratory, a Massachusetts Institute of Technology research program rf' _ 
supported in part by^^ the Advanced Research Projects Agency of the 
Department of Defense and monitbred by the Office of Naval Research 
under Contract Number N00814-70-A-83G2-008S, 

Reproduction of this document, in whole or in part, is permitted for any 
purpose of the United States Govtrnwiiit, ^ ' 



Tablt of Contents 



Introduction 



1-1 Flowchart of the System 

1.2 Picture Models 

1.3 The NAPOLEON Example 

1.4 Plans 

1 .5 Linear Debugging 

1.6 Insertions 

1.7 Geometric Knowledge 



The Annotator 



■ V * 

2.1 Process Annotation 

2.2 Semantics for Turtle Primitives 

2.3 Plan-Finding Advice 

2.4 Debugging Advice 



The Plan-Finder 

• 3.1 Plan-Finding as SeaVch^ 

3.2 Linear Plan Space 

3.3 Finding the Plan foi| Stickman 

3.4 Non-Linear Plans ajidlSelf Criticism 
3*5 Summary of the Plan-linder 



The Debugger 



c 



4.1 Model Violaitions 

4.2 Debugging as Search ^ 

4.3 Ordering Multiple Violati^s 

4.4 Finding The Proper Repair-Point % > 

4.5 Imperative Knowledge 

4.6 Assumption and Protection. 

4.7 Deciding Between Alternative Debugging Strategi 

4.8 Summary of Debugging Concepts ^ 

4.9 Classification of Bugs 



Conclusions 

5.1 Top-Level Debugging Guidance * 

5.2 Generalizability of Debugging Techniques 

5.3 Extensions ^ 

Bibliography ^ » ' ^ ^ • * 



3 



Goldstoin 



Introduction 



' MiyGQIMG SIMPLE PICTURE PROGRAMS 

!• IKTROpOCTION 4v 

This paper reports on progress in the developaiFnt-of a monitor for 

■ ■■ ■ ' ' ■ 

debugging elementary prograns. Such research is inportant both for its 

practical applications as well as for its inV'estigation of concepts 

^ s 

o • ■ • ... % ' 

which ^are fundamental to programing skill* A copiputtr aonitor called 

MYCROFT has been designed that can repair simple programs for drawing 

pictures [Goldstein 1974]. The reasons to develop, such monitors are; 

1. to provide a more precise understanding o^ the nature of ' 
programming skills; y 

2e to facilitate the development of machines capable of 

debugging and expanding upon the programs given them by ■ , 
humans; and 

3. to produce insight into the problem solving process so 
that it can be described more constructively to students. 

NYCROFT is intended to supply occasional advice to a student to aid . 

/ '■' * 

in the debugging of programs that go awry. » <^Just as the system's " 
namesalce, Mycroft Holmes, occasionally supplied advice to, his younger 
brother Sherlock on particularly difficult cases.) In this interaction, 
the user supplies statementt that describe aspects of the intended 
picture and plan, and the system fills in details of this connentary,' 
diagnoses bugs and suggests corrections. In this paper, however, I 

« 

shall not emphasize this Interactive role* Instead^ my primary purpose 
will be to describe NYCROFT as a model of the debugging process. This 
is reasonable since HVCROFT's utility as an advisW stems directly from 
its unden^tanding of debugging skill. • 

^ MYCROFT is able to correct the programs responsible for the bugged 
pictures shown in figures 1.1, 1.3, 1.4 and 1.5 so that the intended 
pictures are achieved. In this paper, the debugging of figure 1.1, a 
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typical «xample, will bt thoroughly^ fxplalned. Flourt* 1.3, 1.4 and 1.5 
are corrected In analogous ways: see [Goldstein 19743 for details. ' 






Intended MAN 
FIGURE 1.1 




Picture drawn by NAPOLEON 
FIGURE 1.2 




INTENDED TREE 



1^ 



Picture drawn by 
bugged TREE program 



FIGURE 1.3 
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Intended WISHINGWELL 



r 



Picture drawn, by bugged WISHINGWELL 
program 



FIGURE 1.4 




Intended 
FACEMAN 



/ 
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Picture drawn by bugged 
FACEMAN program 
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These pictures are dravm by program nanipulatioh of a graphics 
device called the .tu rtl e which has a fien that can leave a tracK along 
the^ turtle ' s path . Turtles play an important role in the LOGO 
environment where children \%wxi problem solving and mathematics by 
progrgnuning display turtles, physical turtles with various sensors, and 
music boxes [Papert 1972]. Turtle programs have proven to be an 

excellent starting point for teaching programming to chil<[ren of all 
ages, and therefore provide a reasonable initial prdblem domain for 
building a program understanding system. 

The context of MYCROFT's activity is the interaction of three kinds 
of description: graphical (i.e. the picture actually drawn), procedural 
(the turtle program used to generate the picture) and predicative ^the 
collection of statements used to describe the desired scene). For 
MYCROFT, debugging is making the procedural description produce a 
graphical result that satisfies the set of predicates describing intent. 
Thus, debugging here is a process that mediates between different 
representations of the same object. 

1 . 1 FLOWCHART OF TP SYSTEH 

The organization of the monitor system is illustrated in^ figure 1.6. 
Input to MYCROFT consists of the user's programs and a model of the 
intended outcome. For the graphics world,, the model is a conjunction of 
geometric predicates describing important pr'opertiea of the intended 
picture. MYCROFT then analyzes the program, building both a Cartesian 

annotation of the picture that is actually drawn and a plan explaining 

« / ■ 

the relationship between the program and model. (Any or all of the plan 

can be supplied directly by the user, thereby simplifying MYCROFT's 
task.) 
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■J . ■ , 

The next step is for the system to ijiterpret the program's 

performance in terms of the model and produce a description of the 
discrepancies. These discrepancies Hire expressed as a list of the 
violated model statements. The task is then for the debugger to repair- 
each violation. The final output is an edited turtle program (with 
copious commentary) which satisfies the model. (Occasionally, the^plan 
that MVCROFT hypothesizes requires implausible repairs— for example, 
major deletions of user code—resulting in the debugger asking the plan- 
finder for a new plan.) T 

The remainder of this first section describes the debugging of 
NAPOLEON (figure 1.1) and introduces some Important ideas about the 
nature of plans. Section 2 'describes the annotator used to document the 
performance of turtle programs. Section 3 intrdduces the £lari-finder 
and section 4 discusses the debugger. 'Section 5 concludes with 

suggestions for future research., ■ a ' ■ " 

<j . •- 

1.2 PICTURE MODELS 

To Judge the success of a program, MVCROFT requires as input from 
the user a description of intent. A declarative language has been 
designed to define picture models. These models specify important 
properties of the desired final outcome without Indicating the details . 
of the drawing process. The primitives of the model language are 
geometric predicates for such properties as connectivity, relative 
position, length and location. The following models are typical of 
those that the user might provide to describe figure 1.2. 
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. MODEL' MAN 

' Ml PARTS HEAD BODY ARMS LEGS , 
, M2 EQUITRI HEAD 

M3 LINE BODY <, N ' 

M4 V ARMS* V LEGS 

MS CONNECTED HEAD .BODY, CONNECTED BODY ARMS, CONNECTED BODY LEGS 
M6 BELOW LEGS ARMS, BELOW ARMS HEAD 
. ' END' 

, ( ' MODEL 'V 
\ Ml PARTS LI LZ 

•M2 LINE LI, LINE 4.2 
H3 CqNNECTED LI L2 (VIA ENDPOINTS)y 

END ■ 

■ MODEL EQUITRI 

, Ml* PARTS (SIDE 3) (ROTATION 3) 
. - , M2 FOR-EACH SIDE (« (LENGTH SID^) 100) 

M3 FOR-EACH ROTATION (« (DEGREES ROTATION) ,120) 
m RING CONNECTED SIDE 
END 

The MAN and V modjBls are underdetermined: they do not describe, for 
example, the actual size of th^ pictures. The user has latTEi^e in his 
^ description of intent because /lYCROFT is designed only to debug programs 



that are almost 'correct; Tlieihefore, not only the nodel, but also the 
picture drawn by the prograa and the definition of the procedure provide 
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cluGS to the purpose ojT the i>ro{fru. 

1.3 THE IjikpOLEON EXAMPLE ' 

• ■ ^ • \ 

HYCROFT is designed to repair a simple class of procedures called 

Fixed-Instruction Programs. These are procedures in which the 

primitives are restricted to constant inputs. Sub-procedures are 

allow^>df^J)owever, no conditionals, variables, recursions or iterations 

arc permitted. Given below^re the three programs which drew figure 

1.1— NAPOLEON, VEE, and TRICORN. The "<-" coimnentary is called the plan 

and was generated by HYCROFT to link the picture models— MAN, V and 

EQUITRI--to the programs. 
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<- (accomplish nan) 
<- (accomplish legs) 

- (accomplish (piece 1 body)) 

- ( insert arms body) 

- (accomplish (piece 2 b*dy)) 

- (setup heading (for head)) 

- (accomplish head) 



TO NAPOLEON 
10 ,VEE 

20 FORWARD 100 
30 VEE 

40 FORWARD 100 
50 LEFT 90 
60 TRICORN 
END 

TO VEE 
10 RIGHT 45 
20 BACK 100 
30 FORWARD 100 
40 LEFT 90 
50 BACK 100 
60 FORWARD 100 
END 

TO TRICORN 
10 FORWARD 50 
20 RIGHT 90 
30 FORWARD 100 
40 RIGHT 90 
50 FORWARD 100 
GO RIGHT 90 
70 FORWARD 50 
END 

Tho turtle command FORWARD moves the turtle in the direction that it 
is currently pointed: RIGHT rotates the turtle clockwise around its 
axis. A complete description of LOGO can be found in LAbelson 1974 J, 
but is not needed here. 

A Cartesian representation of the picture is generated by the 
annotrttor that describes the performance of the turtle program. Tho 
plan is used to bind sub-pictures to model parts. This allows MYCROFT 
to iutcrprot the program with repect to the model and produce a list of 
violated model statements. HYGROFT produces'the following list of 
discrepancies for NAPOLEON: 



(accomplish v) 

(setup heading for 11) 

(accomplish 11) 

(retrace 11) 

(setup heading for 12) 

(accomplish 12) 

(retrace 12) 



- (accomplish equitri) 

- (accomplish (piece 1 (side 1))) 

- (accomplish (rotation 1)) 

- (accomplish (side 2)) 

- (accomplish (rotation 2)) 

- (accomplish (side 3)) 

- (accomplish (rotation 3)) 

- (accomplish (piece 2 (side 1)) 




(NOT (LINE BODY)) 
(NOT (BELOW LEGS ARMS)) 
(NOT (BELOW ARMS HEAD)) 
(NOT (EQUITRI TRICORN)) 



;The body is not a line. 

;The legs are not below the arms. 

{The arms are not below the head. 

{The head is not an equilateral triangle. 
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MYCROFT is able to correct these bugs and achieve the Intended picture 
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using both planning and debugging knowledge. 



1 .4 PLANS ■ ^ 

This section introduces a vocabulary for talking about the structure 



of a procedure which Is useful for understanding both the design and 

a ■ ■ ■ . M 

debugging of programs. A Min^step is dtfintd as tht code required to 
achieve a particular sub-goal (sub-picture). A grepar^tor^^ 
consists of code needed to setup » cleanup or interface between main** 
steps. Thus, from this point of view, a program is understood as a • 
sequence of main-steps and preparatory-steps. A similar point of view 
is found in [Sussman 1973 J. The plan consists oC^the purposes linking 
main- arid preparatory-steps to the model: in the turtle world, the 
^purpose of main-steps is to accompli sh (draw) parts of the model; and 
the purpose of preparatory-steps is to properly setup or cleanup the 
turtle state between main-steps or, perhaps* to ^trace over some 
previous vector. 

A modulais main-step is a sequence of contiguous code intended to 
accomplish a particular goal. This is as opposed to an interrupted- 
main-step whose code is scattered in gieces throughout the program. In 
NAPOLEON, the main-steps for the legs, arms and head are modular; 

however, the code for the body Is interrupted by the insertion of the 

t 

code for the arms into Its Midst. The utility of making this 
distinction is that Modular Main-steps can often be debugged in private 
(i.e. by being run independently of the reMainder of the procedure) 
while interrupted Main-steps conMonly fail because of unforseen— 
interactions with the interleaved code associated with other steps of 
.the plan. 

Lihe§r|,ty is in iMportant design strategy for creating programs. It 
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has two^stages,. The first is to break the .task into independent sub- 

■-■X , ■ ■■ , ...;,:„).. : * ' . . ■ 

goals and design solutions (main-stepS) for ea^i The second is then to 

i# Combiner these main-steps into a single' procedure^ by> concatenatin^^^^^ 

iTi^o'some sequence, adding (where itecessary) preparatory-steps to 

- provide proper interfacing. The virtue of this approach is that it « 

^ divides the problem into manageable sub-problems. A disadvantage is 

that occasionally, there may be constraints on the design of some main- 

step" which are not recognized when that step is designed independently 

of the remainder of the problem. Another disadvantage is that linear 

design can fail to recognize opportunities for sub-rbutinizing a segment 

of code "useful for accoim)lishinfl more than one main-step. A li near iJlan 

u will be definad as a plan consisting only of modular main-*steps and 

* • • ' - ' .. '. ■ *^ . . . • 

preparatory steps; a non- linear plan may include interrupted main-steps. 

" ■ ' ■ ■ - . . ''' ■ i _ <■ - ' .' ■ " . ■ ■ - 

, . ' ' . ■ : ■ ■ . s ' ■ , . .. ' , ' 

.U5 LINEAR DEBllGGI^ 

' Linearity is a power-ful concept for debugging as well as for ' 
designing programs. MYCROFT pursues the following linear approach Xo 
correcting turtle programs: the debugger *s first goal is t^> fix each 
main-step independently so that the code satisfies all intended 
properties of the model part being accomplished. Following this, the 
main-steps are treated as inviolate and relations between model parts 
are fixed by debugging preparatory-steps. This is not the only 
debugging technique available to the system, but it is a valuable one 
because It embodies important heuristics (1) „concerning the order in 
which violations should be repaired and (2) for selecting the repair- 
point (locatidn in the program) at which the edit for each violation 
should be attempted. J 

Following this linear approach. HYCROFT repairs the crooked body and 
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" : ' : ' ' ■ ' ■ . ■ ■ 

the op^n head of NAPOLEON befkire correcting thet BELOW relations. 

Repairing these parts is done on the basis of knowledge described In th« 

\ • ■ . ■ . ■ ; ^ ■ - ' 

n^xt two sections. Let us assume for the rimatnder of this section that 

these property repairs have been made NAPOLEON ^appears as in figure" 

1.7 — and concentrate on the debugging of the violated relations. 




NAPOLEON With parts correGtedr NAPOLEON with statement 15 

. ■. ' as RIGHT 135 

FIGURE 1.7 • : , FIGURE 1.8 / 

Treating main-steps as Inviolate and fixing relations by modifying 
setuiJ steps limits the repair of (BELOW LEGS ARMS) to three possible 
repair-points: (I) b«f:ore the leg$ as statement 5, (2) before the ^irst 
piece of the body as statiment 15 and (3) before^accompiishlng the. arms 
as statement 25. HYCROFT understands enough about causality to know 
th^at there is no point in considering edits followinji the execution^of 
statement^ 30 to affect the arms or legs. The exact changes to be made 
are determined by imperative semantics for the mo^tel primitives. This 
Is procedural knowledge that generates, for a~ given predicate and 
location in the prograiB, some possible edits that would make true the 
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violated predicate. NYCROFT generally coniiders-JilternatiVe strategies 
for ccirrecting a given violation :• it prefei*s those edits which produce 
the most beneficial side effects, make ininjlmkl change? to the user's , 

code or most closely satisfy the abstract forO of the plan. 

• ' ° ■ ■ ■ " ■ ' - *. ' 

For BELOW, the im|»erativq semantics direct ^EBOG to place the legs 

below the arms by„adding rotations at the setup s*eW. More drastic 

modificaftions to the user's code are possible $uch>as the addition. of 

pojiftion setups which alter the topology of the pict^e; however, 

MYCROFT tries- to be gentle to the turtle program (us irta the heuristic 

that the user's code is probably almost correct) and considers larger 

a" ' ' ' ' ' \ 

changes to the program Only if the simpler edits do not succeed. ^ The 

■ ■ ^ 

first setup location considered is the one innediately 'prior to 
accomplishing the arms. Inserting a rotation as statemdht 25, however, 
does, not correct the violation and is therefore rejected. The next 
possible edit point is as statement 15. Here, the addition^f RIGHT 135 
makes the legs PARTLY-BELOW the arms and^ produces figure 1.8. This edit 
is pbsslbie but is not- preferred both because th< legs and arms now 
overlap and "because the legs *are not COHPLETELY-BELOW ,the arms. MYCROFT 
is cautious, being primarily a repairman rather than a '(^signer, and is 
reluctant to introduce new connections not described, in the model. 
Also, given a choipe,- MYCROFT prefers the most constrained meaning of 

the model predicate. If the user had intended figure 1.8, then one 

. ■ ■/ 

would expect the model description to include additional declarations ' 

' ■ ' 

such as CCONNECTED LEGS ARMS), and (PARTLY-BELOW LEGS ARMS). 

Adding RIGHT 90 as statement 5 achieves (COMPLETELY-BELOW LEGS ARMS) 

and j:he NAPOLEON program now produces the intended picture (figure. 1.2) . 

This correction has beneficial side effects in also establishing the 

.proper relationship between the head and arras, confirming for MYCROFT 
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that the flidit is reasonable, since a particular underlying causB is 

often responsible for many biigs. Thus the result of (DEBUG (BELod LEGS 

ARMS)) is: . . . , 

5 RIGHT 90 <* (setup heading 'such*that (beloH legs arras) 

(below arms head}) 
(assume («^ (entry. heading) 270)) 

The a ssume ' comment records the entry state with respect to which the 

edit was made. If the program is run at a future time in a new 

0 ■ ■ " ■ . ■ ' ... 

environment^ 'then debuigging is simpiified. The cai)se of a BELOW 
violation will now Immediately be seen to be an incorrect assumption^ 

it 

and the corresponding repair is obvious insert ^ode to satisfy the' 
entry requirei)ents described by the assumption. Tiiis illustrates the 
existence of levels of cfommentary between the model and the program^ 
each layer being more specific p but also more closely tied to the 
particular code .and runtime environment of the program. 

Linear debugging greatly restricts the possibilities that must be 
considered to repair a violation* It is often successful and 
constitutes a powerful first attack on the problem of finding the proper 
edit; however » it is not infallible. Npn"" linear bugs due to unexpected 
interactions between main-steps would hot be caught by this technique. 

.Figure 1.9 illustrates a non-linear bug. (INSIDE HOUTH H^AD) is 
vi/d^ed but It cann^\^be repaired by adjusting the interface between 
these two parts (indicated in figure 1.9 l^y the dotted line OP) since 
i^the mouth is longer than the diameter of the head. The imperative 
semantics' for fixing INSIDE recognize this. Consequently i NYCROpf 
resorts to the non*llnear technique of modifying main'^steps to repair a 
relation bettween parts.- The imperative semantics suggest changing the 
size of one of the parts because this transformation does not affect the 
shape of the part and consequently. will probably not introduce new 

16 " 
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violations in properties describino the part. Advice is required from 
the .user to know whether sh^in^cinfl^the wouth* is to b* preferred to 
expanding the he«d. Two more non-Unear -debugging techniques are 
discussed in the next two sections: one is based upon knowing the 
abstract form of plans, and the other uses doMln-dependent theorens 
about global effects. 



^ 1.6 INSERTIONS 

In programming, an interrupt is a break in nonB#l processing for the 
purpose of servicing a surprise. Interrupts represent an important type 
of plan: they are a necessary problem Solving strategy when a process 
must deal with unpredictable events. Typical situations where 
Interrupts prove useful include servicing a dynamic display, and, 
V arbitrating the conflicting demands of a time sharing system. In the 

; ^eal world, biological creatures must use an interrupt style of 

~ ^ processing to deal with dangers ^I'^their environment such as predators. 
A very simple type of interrupt is one In which the program 
associated with the Interrupt 1$ performed for Its side effects and Is 
' ?$**fr*r«ns^rent, I.e. the machine is restored to its pre-interrupt 

ERIC 27 
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State before ordinary processing is resumed. As a'result, the main 
process never notices the interruption* In the turtle world, an 
analogous type of ^orgj||«ii2ation is that- of an inserted ^nain^rretr^ 
(inseci^n).. It naturally ari;ies when the turtle, while accomplishing 
one part of a model (the interrupted main-step), assumes an appropriate 
entry state for another part (the iriil&ertion)* An obvious planning 
sl^ategy is to insert a sub*procedura at such a point in the%execution 
of the interrupted main*-step. Oftenr the insertion .will be state*- 
transparent: for turtles, this is achieved by restoring the heading, 
position and pen state* t^e insertion of the arms into "the body by 
statement 30 of NAPOLEON is an example of a position^ and pen- but not 
heading- transparent insertion* 

Insertions do not share all of the properties of interrupts. For 
example, the ijisertion always occurs at a fixed point in the program 
rather than at some arbitrary and unpredictable point in time. Nor does 
the insiertion alter the state of the main process as happens in an error 
handler.. ^Hpwever, if one focusses on the planning process by which the 
user's code was written, then the insertion as an intervention 'in 



accomplishing a main-step does have the flavor of an interrupt. 

tk % ■ . 

The FINDPLAN module aids the debugger in a second way beyond just 
the generation of the plan. This is through the Creation of caveat 
comments to warn the debugger of suspicious code that fails .to satisfy 
expectations based on the abstract form of the plan. In particular, if 
FINDPLAN observes an insertion that is not transparent, then the 
following caveat is generated: 

30 VEE <- (caveat findplan (not (rotation- transparent insert))). 
^The non-transparent insertion may have been intentlotral^ e.g. the 
preparation for the next piece of the interrupted main-step may have 

18 ' 



Goldstein 17 Introduction 

been placed Within the insertion. The user's program may have prepared 
for the next main-step within the insertion; Hence, FINOPLAN does not 
immediately attempt to correct the anomalous code/ Only If subsequent 
debugging of some model violation confirms the caveat, is the code 
corrected. Ther%:^ifi often be many possible corrections for a 
particular model violation. The caveat is used to increase thfe 
plausibility of those %dits that eliminate FINDPLAN's complaint. In 
this way, the abstract form of the plan helps to ouide the debugging. 

For NAPOLEON, analysi-s of (NOT (LINE BODY)) leads NYCROFT to 
consider (1) adding a rotation as statement 35 to align the second piece 
of the body with the first or (2) placing this rotation into VEE as the 
final statement. Ordinarily, linear debugging would prevent the latter 
as it does not respect the inviolability of Main«steps. However, It is 
chosen here because of the corroborating complaint of FINDPLAN. The 
underlying cause of the bug is a main-step error (non-transparent 
insertion) rather than a preparatory-step failure. Thus, 
(DEBUG (LINE BODY)) produces: 

70 RIGHT 45 <- (setup heading such-thato( transparent vee)) 

1.7 GEOHETRIC KNOWLEDGE 

i 

Linearity, preparation and interrupts are general problem**solving 
strategies for orflanizing ^oals into programs. However, it is Important 
to remember that domain-dependent knowledge must be available to a 

0 

debugging system. The System must know the semantics of the primitives 
if it is to describe their effects. 

The debugger must also have access to domain-dependent information 
to repair wain-steps in w^ch the sub-parts must satisfy certain' global 
relationships. For example ,*TRICORN hps the bug that the triangle is 



not closed. Each main-step independently achieves a side but the sides 
do not have thp proper global relationship. Debugging is simplified by 
the explicit statement in the model that: ^ 

(FOR-EACH ROTATION (« {DEGREES ROTATION) 120)). 
But suppose the model imposed no constraints on the rotations. Then the 
design of the rotations would have to be deduced from such aeometric 
knowledge as the fact that N equal vectors form a regular polygon ifv^ 
each rotation equals 360/N degrees. * « 

The pieces of an interrupted-step such as the first side of TRICORN 
are nbt always separated by a state-transparent insert. (This would be 
a local interruption.) Instead, it is possible that more global 
knowledge is needed to understand the properties of the intervening code 
which justifies the expectation that the pieces will properly fit 
together. In TRICORN,*^ the second piece (drawn by statement 70) must be 
collinear with the first (drawn by statement 10). The global property 
of the code which Justifies this is that equal sides and 120 degree 
rotations 'results in closure. Thus, debugging violations of globally 
interrupted-steps requires domain-dependent knowledge. 

Geometric knowledge does not replace the need for general debugging 
strategies: these are -still very Important to narrow the space of 
possible repair-points for correcting a given violation and to choose 
between alternative corrections. Section 4 discusses both types of 
knowledge in greater detail. 

A. ■ - 
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2- THE ANNtfTATOR ' .. \ 

> . , . , ■ ■ 

Da'jugfiina Is Imposiible witho it flood description of a program's 
purpose and performance. Mi CROFT begins with the prooran and a model 
describing its intended result. Two forms of additional comjnentary anc 
then aenerated: Performance Annotation documents the effect 'of running 
the prograia \.hile the Plai explains the intent. This conwentary is 
oroanlzed as sets of asaortious in "a database, bound together into 
sequences roprf3sent 115J > 'jnt harjprncri affd why. Figure 2.1 shows part of 
tho databdio generated to dpscrihe »"APdLEON. The nodes aro organized so 
that the horizontal ax* j -cpresents time and is used to answer suqh 
caudal questions as whif c! auges oci.urred to which state variabj.es and 
which code was rrsposis b«' for tl.c5Ke chanjes. Similar data structures 
ior dof.Gribin«j prouruir u'd ui.ed by r.ihlman [1973] and Sussrann 11973 J.. 

The vei ti<. il tr i.; . opresenl teleological abstraction and 
cxplaivis ttiB purpose of i.h( code. Models fit into this descriptive - 
frtuaowbrR as tlie hJt^Iief.t level ci' abstra;tion. They describe the final 
gorl With i,t ties to 1 ciiiq plans or chronological performance. The 
n« rt If vel is the j ar in/^icniifly thfi rub-goal organization for 
accomi linhlna t\i ^ r f h i . Filially, Lhf te eology rests on a description . 
of th*' N 'ual i pri ini. .1 i of th » tt prrira* when executed in a 

MYCROFT cnalyVts a program by first building a complete 
,perform«ace annotation ?ind then applying the plan-finder to assign 
purposes to t!ie code. Pe.'rorH>»jice annotation is iaccompllshed by runnlnti 
the user's turtle program in a "cd>flful myde" which produces three kinds 
of doscrlf tion. 

21 
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■ » ' ■ 

!• Process Annatation is a description of the output of the 
program. It consists of' a record of. the effecU of executing 
each progran- statement* For turtles, this consists of the 
creation of sectors, vector structures, rotations and points. 

2. Planning Advice suggests the segmentation of the program with 
respect to accomplishing the model on the basis of such 
criteria as global conniBctlons. ' 

3. Debugging Advice describes suspicious code by caveat comments 
which aid in subsequent debugging. 

Details of these three kinds of performance annotation are given below. 

The FINDPLAN algorithm is then described in section a. 

• ° 

2^1 PROCESS ANNplATION ° 
Process annotation provides a description of the output of a 
program and its sub-procedures in terms of some language appropriate to 
the purpose for which the prMram was designed. For example, the 
performance annotation for an arithmetic program might be in terms of 
mathematical equations to be^satlsfied at various points in the - 
computation LFloyd 1967J. For turtle programs, an obvious choice is to 
produce a Cartesian description of the picture drawn by the program. 
Annotation should reveal the basic effects of the code, free of vagaries 
of Individual programming styli. This would include knowing the 
description of a vector, regardless of whether the actual coiwnand is 
FORWARD, BACK or SETXY. (The last command moves the'turtle to an 
absolute position on the screen.) 

Annotation produces a sequence of frames. A frame is getferated 
to describe the execution of each primitive and sub-procedure call. 
Each frame is a set of assertions specifying (1) any changes to the 
turtle's state and (2) the properties of any picture tlemants which have 
been created. The turtle's state consists of the values of the global 
variables :HfcAUING, :POSITION and :PEN. Picture elements (created as 
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side effects of executing turtle coMHands) are vectors^ rotations^ 
points and structures (vector sets drawn by recognizable code segments 
such as sub**procedures}« , » ^ 



2,2' SEMANTICS FOR TURTLE PMMinyES ^ 

The process annotation is generated by taperative semantics 
associated with each turtle primitive , lliese semantics describe the 
performance of the turtle coimand, 

SEMANTICS FOR (FORWARD :DISTANCE) ; Draws a vector.^ 

(sVECTOR (OENERATE-NAHE 'V)) > 

;A11 verticesi rotations, vepto^s and structures 

;are given unique names to facilitate later debugging. 

;If subsequent investigation reveals that the 

;particular object has been given a^ljibel by. 

; the user p then the system name j[t Wplaced by the 

;user*s identifier. 

;Describe the Vector in terms of its direction and length. 

(ASSERT (■ (DIRECTION :VECTOR) :HEADING}} 
(ASSERT (« (LENGTH :VECTOR} : DISTANCE}} 

(ASSERT (« (VISIBILITY :VECTOR} <WNUP, PENDOWN, RETRACE>} 
{Update the State of the Turtle 

(:POSITION <— (FORWARD :DISTANCE}} 

; FORWARD : DISTANCE outputs coordinates of the new 
; position. Set the turtle state variable '.POSITION 
;to this new location of the turtle. 

(:POINT<-- (GENERATE-NAME •P)) 

;If the coordinates are unique, bind :POINT to 
;a new name for this position. If not, use the 
;old name for the position. If a name already 
; exists for this position, record the connections , 
; occurring at this point between : VECTOR and 
{previous vectors. 
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" ■ . ./ . ■ 

•SEMANTICS FOR (RIGHT :ANG^E) {Rotates th» turtle. 

•(:R0TAT10N <— (GENERATE-NAME 'R)) 

;Describe the Rb'tation in terms of its vertex and degrees. 

(ASSERT (» (DEGREES :ROTATION) :ANGLE) 
(ASSERT (« (VERTEX ;ROTATION) :POSITION) 

;Update the State "of the Turtle 

' •■ ■ . ' • / . 

(rHEADING (RIGHT :ANGLE)) jRIGHT outputs th« nuw heading- 
At the levol- of the process, actual numerical values arc 
determined for the above properties. Bepausi these assertions depend 
upon the particuljr state of the initial environment, this is the most 
specific, least abstract level of commentary when compared with the 
model and plan. 

2.3 PLAN-FINDINQ ADVKE ' ' 

jft Alth 'a^jh perforaiiico annotation does not examine the model, it 
can reveal' clufts to the groupina of the rser*s program into main- and 
preparatory-steps which aia in finding the plan. ^ . ' 

1. Sub-prbcofluros that draw visible sub«*pictur9« - ^ . 
arc hypothesized to be main-steps that accomplish 

some model part. 

2. Haxim.l s ^neixes of "invisible" primitives such 

as (a) vnctta ^ Vawn either by retracing or with the 
pen up, (b) rotations, and (c) PENUP commands are 
gioupod tyjeihor as possible preparatory-steps. 

3. Haximal scqueuc^s oi visible vector instructions 
plus any intervening rotations are grouped as 
possible main-steps. 

4. Global connections suggest code boundaries. ThuSi 
maximal soqi oKces of visible vectors ciii be segmente/J 
on the basis of such connections. \ 

This segmentation is ttntativo and may be revised in the light of later 

consideratiim of the model. 

Suppose MAPOLEON Wt s not subroutinized and, Insteadrthe ai ms. 

Jit) 
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tlBgs and head were open**coded (i.e, coded as iJ<*linef sequences of 
primitives rather than subroutinized)* The a^pve clues would be- quite 
useful by utilizing the global connections between the body« and limbs in 
the picture to suggest nain-step boyndar|Les. 

- t '. 

2.4 DEBUGGING ADVICE . 

Oddities in the form of the program can create a suspicion of 
bugs. The annotator notices tl^ese violations using Rational Form 
Criteria which are sensitive to tinexpected and aip^arently erroneous 
code. Caveat comments are generated describing these complaints. 

Rational Form Criteria are based upon expectations of simple ^ 
efficiency and consist of noting sequences of contiguous uses of the 
same primitive^ such as FORWARDt RIGHT or PENUP. The annotator 
considers the code to be odd: why didntt the user simply coalesce them 
into a single call with a larger input or» in the case of PENUP, Include 
only the? first instruction?'^ The answer may be that the user has 
forgotten to insert additional instructions. An example would be where 
the user had forgotten to insert several RIGHT comttands into a sequence 
of FORWARD instructions. A caveat stating- that code may be missing is 
placed between each pair of elements in the sequence of FORW^D*s. A 
^Violation of rational form occurs in the following triangle procedure 
because the user has forgotten the first rotation. ^ 
TO TRI 

Id FORWARD 100 <- (caveat annotator RATI0NAL-FORM-VI<}LATIOM 

(sequential-primitive 10 'BO)) 
30 FORWARD 100 ) 
40 RIGHT 120 « 

50 FORWARD 100 ' 
END 

An edit that inserts a rotation into such a sequence of FORWARD 
Instructions would eliminate the rational form violation and therefore 
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be preferred In competjltion with other corrections which do* not explain 
the anpotator • s complaint . If the debUflger corrects the program by 
eliminating the annotation caveat/ then the underlying cause of the 
error is considered to bt '^Kissing Gode*, 
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3, THE PLAM-FIMDER 



After performance annotation* the next step in describing the 
program is to find the plan* The strategy is to attempt initially to 
find a linear plan » i,e. to match model parts with modular main-^steps 
and relations between model parts with preparatory**steps. This approach 
serves to limit the search space^ but it is not adequate to recognize 
interrupted main«*steps and insertions. These '*non*llnearities** are 
suggested by suspicions about the cause of violations implied by the 
conjectured linear plan. These suspicions are that the cause of the 
violation is not an error in the user's program but a mistai^e in the 
plan«^finder's linear interpretation of the planV If additional evidence 
confirms the suspicion » the plan«finder corrects its Linear analysis and 

finds the correct global or insertion type of plan. This approach of 

/ ■ " ■ V • 

first pursuing a linear interpretation and only 'debugging' this 

« 

approach in response to anomalies is a powerful reasoning mechanism for 
searching complex spaces* As was noted in section l* the debugger uses 
a similar analysis to simplify finding ihe proper repairs* 

Plan-finding obtains some guidance from the picture and some 
from the program. The picture supplies such clue5 ast 

'(a) global connections which suggest sub^'picture boundaries; 

(b) retracing which suggests inserts; 

and (c) violations of model statements which are then used both as 
plausibility criteria (to distinguish between alternative 
interpretations) and to^generate suspicion demons (which look 
for non-linear jplanning sti^uctures) • ^ 

The t>rqgr^ supplies quite different clues about intent. This includes: 

(a) sub^procedure structure which aids in recognizing main<-steps; 

and (b) the order in which the picture is drawn which^ when combined 
- with programs-writing criteria* suggests the order in which the 
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model parts are accomplished* 



aa^ PLAW^FIN^ ' .^^^ \ 

Finding the plan can be conceptualized as a search of a space of 
"partial plani*. The search begins with the nodel. the program and the 
performance annotation. A partial plan is an explanation of some 
fraction of the model in terms of the program. Given a partial plan, 
its daughters are the result of generating alternative explanations for 
one of the remaining unassigned model parts. A terminal node is reached 
whfen all of the model parts have been eicplained and a comi^lete plan is a 
path from the root to a terminal node, vfherein an explanation is 
provided f or kow each model part is achieved. 

A partial plan consists of PURPOS E conments which assign model 
predicates to code, unassigned model parts, ex pectations , the implied 
RSrtll?! itt>erpretation, and demons . 

PURPOSES - These are the basic statements of a plan .and appear as 
"<-" commentary in the NAPOLEON procedures. Five Kinds of purposes 
are generated by FINDPLAN; accomplish, insert, setup, cleanup and 
retrace. 

UNASSIGNED HODEL PARTS - The model specifies a list-of parts. These 
are either prlmitiv* picture objects (vectors or rotations) or sub- 
models. An unassigned part is one without a PURPOSE statement 
indicating how it is to be accomplished. ■ 

EXPECTATIONS - These are predictions of which part is expected to be 
accomplished by the- next main-step. They are based on applying 
program-writing criteria of efficiency and simplicity to the model. 
See the discussion of Analysis by Synthesis in the next section. 

* ■ ■ , . * 

PARTIAL INTERPRETATION - Model predicates can be eva/uated by 
ordinary Cartesian geometry using the binding of model parts to code ■ 
(which the plan implies) and an annotated description of the code's 
effects. A partial interpretation consists of those model' 
predicates whose truth value is known given the current partial 
interpretation. 

DEnONS - Demons are used to explain subsequent code in such a way 
that violations in the partial interpretation are eliminated. The 
' elimination results from debugging the system's linear analysis and 

. .39 ■ 
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recognizing the existence of an interrupted or inserted main-step. 
The partial plan is complete «4ien all of the unassigned parts 
are explained by PURPOSES. Debugging is fixing tbe violations of the 
resulting complete interpretation. 

3^2 tlNEAR PLAN SPACE 

The search is neither a standard breadth nor depth first 
exploration of the space. InsWd, the system initially assumes a 
linear structure to the user's plan, looking to assign the parts to 
sequential code segments. The possibility that a part is being / 

K -J- ■ ' , " 

accomplished by disjoint segments of iode or by insertions is not 
considered. This greatly constrains the search space. Branching, 
however, is not eliminated: for a given program, more tfian one linear 
plan will usually be possible. To choose among the alternatives in this 
Mnear plan space, several plausibility criteria are used. 

1. (Advice) The first is to take advantage of user, annotator or 
debugger advice to initialize the partial plan space. Annotator 
advice originates in noticing (1) sub-procedures that have been 
previously associated with a model and (2) open-coded sequences 
identified as having a conmoh purpose on the basis of non-model clues 
like penstate changes and retracing. (See section 2.3.) The first 
produces PURPOSE assertions which form the initial partial plan: the 
second SUGGESTIONS which have the effect of causing open-coded 
sequences to be treated as sub-procedures. Debugging advice is in 
the form of a request that the plan-finder supply a new plan that 
does not make certain hypotheses about the program. This interaction 
arises When the debugger finds all editing strategies for the current 
plan implausible. 

2. (Analysis; by Synthesis) Another method is to consider the model from 
the point of view of program writing. This leads to two forms of 
advice. The first is to assign sub-procedures to model parts if 
possible (on the grounds that the model parts constitute a likely 
plan for breaking the picture into sub-goals). The second is to 
generate expectations for the order in which the parts are to be 
accomplished. This is done by observing transitive sequences of such 
predicates as BELOW and CONNECTED in the model. The heuristic is 
that. that these sequences represent the probable order in j«hich the 
parts are accomplished, thereby minimizing retracing. 

30 
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3. (Static Evailuatiori Function) third nsthod Is a plausibility 
•stiroate of partial plans. This estimati is si»ply the number of 
satisfied model statements and expections minus the nurlkber of 
violated model statements and expectations. If the program is bug 
free and the plan is correct, then the plausibility number will 6e 
maximal. At any instant in time, only those plans with the highest 
plausibility number are explored. After\analyzing a statement of 
code, the plausibility number is recompH|C(l and the active plans are 
rechosen. Inactive plans are "hung" and are riot resumed unless their, 
active brethren become less plausible. \p ' 



As an example, let us consider the problem of finding the plan 
for NAPOLEON. Recall that the procedure is: 

TO NAPOLEON ^ ;See figure 1.1 

10.,VEE ' - • 

20^ FORWARD 100 . 
30 VEE I 
• 40 FORWARD 100 i 
50 LEFT 90 

60 TRICORN I 

END ' ■ . I 

We shall assume that the VEE sub-procedure has been previously annotated 
and asstfbiated with the V model but that TRICORN and NAPOLEOI*/ have Just 
been defined and their purpose is unknown. By considering sub- 
procedures as candidates for accomplishing model parts (analysis by 
synthesis), TRICORN" Is bound to the EQUITRI model . The result is two 
possible initial partial plans. ]rhese are: 

■ i ' 

PARTIAL.PLAN.l: PARTIAL. PLAN. 2: ' 

•10 VEE <- (accomplish legs) 10 VEE <- (accomplish arms) 

30 VEE <- (accomplish arras) 30 VEE <- (accomplish legs) 

60 TRICORN <- (accomplish head) 60 TRICORN <- (accomplish head) 

Further constraints are imposed by FINDPLAN's program-writing 

. expectations. On the basis of BELOW, FINDPLAN expects: 

(accomplish legs) <-> (accomplish arms) <-> (accomplish head') 

The double arrow indicates that the sequence may happen in either 

! 

forward or reverse order. On the basis of connectivity, the 

ERIC 81 ' 
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expectations are: 

(accoiaplish legs) <-> (accoaplish body) <-> (accoaplish head) 
Taken together, the result is that stateaent 10 is believed to 
accomplish the LEGS and statement 30 the ARHS. Thus, PARTIAL.PLAN.l is 
preferred. 

The code of the prograa is then considered statement by 
statement. Statement 20 draws a vector «nd is therefore believed to be 
the BODY.' it might be only a piece of the body but this is not pii<;^sued 
until the linear assumption that^the body is accomplished by a modular 
nain*step is rejected. 

Statements 30 aqd 60 have already been assigned to the- arms and 
head, respectively. As a result, all of the model parts have been 
assigned but statement 40 remains unexplained. FINDPLAN consequently 
bacKtryfks and interprets statement, 20 as only piece pf - the body. A 
demon is created for recognizing the body's completion and plan-finding 
recommences at statement 30. Statement 40 satisfies this demon since it 
draws a vector that begins at the fndpoint of the first piece of the 
body. The result is that it is considered (piece 2 body). Thus, with 
almost no search, the plan for NAPOLEON is correctly deduced. 



TO NAPOLEON 
10 VEE 

20 FORWARD ;i00 
30 VEE 

40 FORWARD 100 
60 LEFT 90 
60 TRICORN 
£ND 



<- (accomplish man) ' 

<- (accomplish legs) 

<- (accomplish (piece 1 body)) 

<- (insert arms body) ^ 

<- (accomplish (piece 2 body)) 

<- (setup heading) 

<- (accomplish head) 
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. # ■ % 

NONt-LINE/WI PLANS m SELF CRITICISH 
^ This stction txpliins how inttrrupttd uid Instrttd Min-sttps 

are r«coaniz«d. Whtn FINDPLAN binds an unassigncd aodtl part H to a 
searaent of codt C and tht rtsulting inttrprttation iaplits aodtl 
violations, thtrt ar« thret possiblt txplanations : 

1. The code is in error: a bug has been discovered. ° - 

2. C is not intended to accoaplish «. Choose another interpretation 

for C. , . 

k .- ' 

, ' ■ ' ''' - - 

3. C accomplishes only a PIECE of Mi The reminder of M is achieved 
( in pieces. 

Possibility 1 requires no special action by FINDPLAN: the 
violation will eventually be passed to DEBUG fior correction. 
Possibility 2 requires that the a different linear pJan be chosen. This 
will occur If the current linear plan becomes less plausible than 
alternative linear interpretations when compared in terms of the static 
plausibility function described earlier. Possibility 3, however, 
represents an error in the plan-finder's linear analysis of the program. 
Hence, to take account of possibility 3, demons are generated. These *' 
demons are looking for better interpretations than the current linear 
plan (i.e. interpretations which do not imply as many violations). The 
following paragraphs describe the creation of such a demon in the plan- 
finding process for TRICORN. 

Suppose FINDPLAN has just decided that statement C achieves 
model part M and tjjat this results in a violation because M is top 
snail. FINDPLAN suspects that H may be being accomplished in pieces. A 
COMPLETION demon. Is created looking for subsequent code CC which would 
eliminate the violation if CC is interpreted as another PIRCE of M. If 
such code is found, the action of the demon is to edit the original 
partial plan so that M is now considered as being achieved by an 
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interrupted main-step. ' If the code between the pieces of the.nain<-step 

returns the turtle to the exit state of the first piece, then it is 

interpreted as being an insertion. COHPLETION demons are also created 

when « vector is too short to acconplish an intended connection. An 

example occurs in the linear interpretation of TRICORN shown below: 

TO TRICORN ; Incorrect linear plan initially deduced. ( 

10 FORWAilD 50 <- (accomplish (side 1)) V 

20 RIGHT 120 <- (accfmplfth (rotation 1)) 

^ 30 FORWARD 100 <- (aCcdmplish (side 2)) ' ' 

;At this point in the plan^-f inding process^ the violatioti 
;of unequal sides occurs » A COMPLETION demon is creati^d 
;that is looking for a vector of length 50 that couXd be 
; interpreted as the remainder of (side 1). 

. 40 RIGHT 120 <- (accomplish (rotation 2)) 
50 FORWARD 100 (accomplish (side 3)) . 

^ o 

;Here the violation of (side 1) not being connected to 
;(side 3) occurs* A ^second COMPLETION demon is created 
{that is looking for another PIECE of (side 1) tjfiat connects 
;to (side 3). 

\ 60 RIGHT 120 (accomplish (rotation 3)) 

70 FORWARD SO (accomplish ?} 

END ^ 

Both of the COMPLETION demons are triggered Xyf statement 70* The result 
is that statement 10 is reinterpreted to accomplish only.^^ 

• ■ ' « 

(piece 1 (side 1)) and statement 70 is assigned the purpose of 
accomplislhing (piece 2 (side 1)). ^ This produces the correct plai}.. 
(OtherHimons are created in the plan--finding process for TRICORN. 
However^ they are never triggered and are therefore not mentioned.) 
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3^5 SUMMARY OF THE PU^ / 

Tht alfloritha for plan-finding pirfoms Will whtn: 

(1) Th8 user supplies advice in the fona of a partial plan; 

(2) The procedure has subroutines; 

(3) The procedure has few bugs. V 
If the prograa is not subroutiniied and is full of bugs» the search 
grows unmanageable and difficulties arise in^electing the Most 
plausible candidate. This penfomance is quite reasonable in the sense 
that sinilar statements are true of a human problem solver investigating 
a strange program. 
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4.1 MODEL yiOLAflONS 

Th« Monitor ii dtsigned to dtbug ■odti ^violations . Thtse «re 
rocoQnized by tht INTERPRET Mdult (stt again flour* 1.0) which co«p«rtt 

the output of a syntactically and sMwintically corrtcj[ turtl* progran 

f ' ' 

(i.e. a progran that is ablr to run to complttion without rtqutsting any 

illegal computations) to the description of intent provided by its 
picture model, using the plan to bind sub-pictures to model parts. The 
result Js alist of violated model predicates. The program. is • 
considered correct when all of these violations have been eliminated. 

Correcting model violations is accomplished by using two types *> 
of procedural knowledge: (1) a collection of general debugging 
strategies for repairing programs and (^2) directions for fixing 
particular geometricand^ogical predicates. Because overall guidance 
1$ derived from the model, we shall/call this type of analysis model- 
driven debugging. 

4.2 DEBUGGING AS SEARCH 

V- A debugging strategy is a sequence of editing commands whose 
effect is to modify the program so that it satisfies its4«odel. There 
are generally mul^le debuggintf strategies for correcting a given set 

■ V 

/ • of violations. These alternative debugging strategies arise from choice 

of the rfimfr-points at which the corrections are to be made as well as 
of the exact meaning t^at the user intended. 

To clarify the issues which arise in selecting the best 
debugging sequence, it is useful to conceptualize the problem in terms v 
of « search metaphor. The space is that of all possible debugging 

ERJC . - 3ti 
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strategies for correpting the progrw. Each node li a set of model 
violations: the origin of the space is th% initial output of INTERPRET. 
An arc Is an edit which which leads to i node containing the new (and 
presumably smaller) set of violations which are produced by the patched 
fcode. Branching occurs for each ppssible patch for correcting a 
violation . A path through the space constitutes a series of edits that 
transform the program to an acceptable form. 

Recognizing the existence of multiple possibilities for 
correcting a program, it.is appropriate to ask what knowledge is used 



to: 



(1) choose the next model violation to^be debugged? 

(2) generate the possible corrections for that violation? 

(3) choose the most plausible correction? 

The following sections answer these questions. Ordering'^ 
Criteria are introduced for choosing the sequence in which the 
violations are debugged. A llnfar approach curtails the number of 
possible edit points which°*are initially considered. The Imperative 
semantics of the model predicates are used to generate possible 
corrections, PJausibility criteria are designed for selecting among 
alternative debugging strategies. 



4.3 ORDERING MULTIPLE VIOLATIONS 

V Multiple bugs are difficult to fix. Guidelines are required to 
order the sequence in which the violations are debugged. These • 
guidelines reflect an understanding of dependency relationships between 
violations, thereby serving to minimize the unfortunate occurrence of a 
correction undoing previous repairs or Introducing new violations. The 
ordering 1$ done on the basis of preferring to repair: 

. Q HI 
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i _ ; 

(^1) bugs in properties of model parts before bugs 
in relations between fiodel parts; 

(2) bugs in intrinsic properties (or relations) before 
bugs in extrinsic properties (or relations); 

and (3) bugs occurring earliest in the teinporal sequence 

of execution* . 1 

The following paragraphs describe these criteria and explain their 

rationale • 

4 .3*1 Debug Propet^ijl J^f^. 

The system debugs violations of grojertljy^ of model parts before 
repairing violations of niljLtipns between model parts « This is bas^d dti 
the important heuristic of first having a successful theory of the pafts 
before attempting an explanation of their interact itins. This is more 
than good style. The behavior of the interfaces is designed relative to 
the entry«exit states of the code for the main-*steps accomplishing the 
parts. To determine the specific state changes to be made at an 
interface 9 the performance of adjacent main^steps must be established. 
Thus the code for sub-'pictures must^be fixed prior to deciding on the 
proper edits to the preparatory«-steps. 

Properties of individual model parts include unary model 

primitives (e.g. VERTICAL, HORIZONTAL and LINE) as well as user-defined 

sub^models (e.g. EQUITRI and V). The most common relations between 

model parts are predicates such as ABOVE, BELOW, and CONNECTED. 
« 

4.3.2 Debug Intrinilc Btfqre Extrljnsic Predicates 

The idea behind the next ordering criteria is to estimate the 
range of possible locations in the program at which the repair might be 
made for each violation, the heuristic is then to fix those violations 

38 
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of nost'liiiited scopt first; both bacaust thty art tasltst and btcause 
of dependtncy relationships. 

Lat tha scop e of a violation be tht codt bttwttn the repair- 
point and the manifestation-point. For a property (P N), N a model 
part, the nanifesutj^^ is the location in tht progrin at which M 
is completed and the truth of the statement (P H) can be evaluated. The 
repair-pgint is the location in the program at which the edit is 
eventually nade to correct the violation. For a relation (R N N), the 
nanifestation-point^is the location in the program at which both M and N 
have been completed and the relation R can be evaluated. 

This criterion would be pointless if there were no way to 
estimate the scope of a v;^olation before entering into the details of 
debugging. However, this is not the case. One method for estimating 
the scope of a violation is to know whether the property of relation is 
intrinsic to the responsible code.' 

A property (PA) is intrinsic to the codt for A if it is 
independent of preceding code and entirely due to the main-step for A. 
Similarly, the relation (R A B) is intrinsic if It is independent of 
code preceding A, assuming that A is achieved before B. Repair is 
simplified by fixing intrinsic predicates before extrinsic ones since 
(1) for intrinsic violations, the possible repair-points are easier to 
find since they cannot occur prior to tht code for A» end (2) the propen 
corrections for extrinsic predicates depends upon the the code being 
intrinsically correct. 

In the world of turtle geoMtry, intrinsic errors are 
distinguished by being independent of the frane of reference: they 
cannot be corrected by translating or rotating the picture. This is 

^ because in the sinplified envi^onnent of fixed*»instruction turtle 

ERIC 3ij ^ 
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programs, coda groups draw rigid bodies. Tht initial interface of a 
code group has the effect of cVtablishing the origin and orientation of 
the sub-picture but does not affect the local relations aaiong vectors. 
Topological predicates (invariant under transforaations that preserve 
connectivity) and geonetric predicates (invariant under translation and 
rotation) are independent of the fraae of reference and therefore yield 
intrinsic violations. Bugs in the following aodel pri«itives are always . 
intrinsic to the code group to which they refer: OVERLAP, ^INSIDE, 
OUTSIDE, PARALLEL and CONNECTED. 

Extrinsic errors are those affected by the initial Environment 
In which the code group is executed. The initial environment consists 
of the bindings of the turtle stat# variables — :HEADING, :POSITION and 
:PEN. These variables control the orientation, origin and visibility of 
the sub-piclure as well as its relation to previously drawn parts of the 
picture. Model predicates which depend on the 'initial state are 
VERTICAL, HORIZONTAL, BELOW, and ABOVE. 

Debugging intrinsic violations first tends to establish the 
proper connections at interfaces. Debugging extrinsic relations like 
ABOVE then becomes simply a matter of establishing the proper heading at 
interfaces. 

-J 

In the turtle world, the distinction between intrinsic and 
extrinsic predicates is particularly easy to make; however, it remains a 
useful debugging distinction in other domains. If a property of a 
program is due to some local data structure (such as a bound variable) 
or local control structure (such as a loop) and is independent of the 
preceding code, then it is intrinsic and worth debugging in private 

before extrinsip properties (whose causes are less easy to isolate) are 

I 

repaired. ^ 
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4^3.3 NAPOLEON'S Violations ■ ' 

The following list of violatlongs for NAPOLEON Is ordered by the" 

: ^ • ■ * ^ . - N» ■ , ■ 

above criteria: . 

(Violations of Properties of Parts of NAl»0LEON) * 
(An Intrinsic Violation —Hanife$ted in Private) 
(NOT fEQUITRI TRICORNI) 

(An Extrinsic Violation.— Not Hanifestfed in Private) ) 
(NOT (LINE BODV)) * . 

(Violations of Relations between Parts of NAPOLEON); 

(Temporal grder -- {legs, arms} accomplished before {arms, head}) 
(NOT (BELOW LEGS ARMS)) ^ ' . 

(NOT (BELOW ARMS HEAD)) 

. ■ . «* 

■ t ■ ■- . - , . • ■ 

4^4 FINDING THE PROPER REPAIR-POINT 

For each violation, DEBUG iDU$t find the proper repair- point in 

■ , / <■ \ ' ' < ' ■ - . ■ . . ■■■■ - - ' ' 

the program at which to insert the correction. Of course, the debugger 

r . 

" . t . „. ■ 

knows that the repair^point cannot follow the codtt for the parts ' 
mentioned in the violation but this is hardly a sufficient constraint. 
Consequently, DEBUG uses two heuristics--Private and Lin^^ar Debugging-- 

to limit the pos&ible locations for the correction* 

. ^ ■ ■ - - . • . 



4.^. 1 Private Debug ging 

An initial heuristic^ for constraining the possible repair-pdints 

for a violated property is to limit consideration to the code directly 

responsible for the model part in question. This is done by running the 

responsible code independently of the larger procedure of which it is a 

part. Specifically, the responsible code is executed with the turtle 

started at the entry state* The violated properties will be manifested 

In this private environment if the main-step is modular. However, if . 

there Is intervening code, l«e. the main-step is interrupted, ^.then the 

4i 
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^ . ^'^ ■ • ' . ■ 

• ' -I 

linear jissumption that the cause Is intrinsic to the responsible code 
and not due to interactions may be wrong. ^ ' 

If the violation is man if est ^ the code group is then debugged in 
this simplified .context, free of the effects of the remainder of the 
original program. Private debugging is used to repair the three 
incorrect rotations of TRICORN. There are np complications when the * 
edited sub«procedure is rejoined to the NAPOLEON super*-|)rocedure. 

The relationship between the picture drawn in private and in 
public is simple for fixed-instruction turtle programs since the picture 
is a rigid body and only its orientation and origin is affected by the 

' . - ' y i;!^- • f . 

initial ei^vironment. For more c6ili|lex programs, difficulty occurs in 
finding a representative private environment and further research is 
iiecessaryf This is similar to the problem of diagram generation in 
geometry theorem proving and to the problem of case analysis in 
automatic program verification* 

The private repair may make assumptions about the entry state to 
the code. If this happens, it will be reflected in ASSUME comments 
regarding the entry state to the toain-step. "^When run again In the real 
coiitext, any conflicts between' assumptions made in private about the 
initial environment and the actual entry state are themselves debugged. 
This is accomplished by adding code to accomplish the assumptions in the 
super-procedure or, if this proves impossible without causing additional 

violations, backtracking and attemptthg an alternative correction in 

• * ■ > • 

private. 

Ah example of this would occur if tn^ model for NAPOLEON had 
declared that ^e body must be vertical. Debugging the body (statements 
20 and 40) in private would result in the assunption being generated 
that the entry heading must be 0 or 180 degree^. The code for the body 
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is then reconsidered, in the context of the NAPOLEON super-procedure. 
The actual entry state to statement 20 does not have SHEADING equal to 0 
or 180 degrees. Consequently, the debugger now attempts to add a 
rotation at some prqcedlng point in the progi^am to 'achieve this entry 
state. This addition will most likely occur immediately prior to 
statement 20 or, perhaps, as the initial setup to the NAPOLEON program. 
The debugger chooses whether to. prefer 0 or 180, and at which repair- 
point, on the basis of side effects, minimal change to the user*s 
program and planning caveats. This set of plausibility criteria is . 
described in section 4.7. 

The system also checks for l)ad side-effects on code following 
the edited sub-group due to a new exit state for the edited code. A 
cleanup step may be needed to eliminate undesirable . consequences of the 
private repairs. Thfe modified main^step may violate protection or 
assumption commentary generated by other edits. If so, the standard 
practice is to either ( 1 ) modify the offended edit in light of the new 
structure for the main-step or (2) backtrack and correcting the main- 
step in private in some alternative way. See section 4.6 for details on 
the protection mechanism. 

Occasionally, when the code is run in private, the violation 

does not occur. This happens because the main--step is not modular and 

the violation is due to code appearing between pieces of an interrupted 

maln-^step. Private debugging remains useful, however, because it 

clearly indicates that the cause of the error is in the intervening 

code. ^ (NOT (LINE BODY)) is an example: the body when run in private is 

f 

indeed a line.. The bug is in the effect of the inserted VEE on the 
heading of the second vector. 

Private debugging is also used to correct intrinsic violations 
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of relations. Recall that the definition of an intrinsic relation is 
that it is entirely due to %he code betweeh the model parts mentioned in 
the relation. Hence, the repair«ppint must occur there. The same 
precautions required when the code is rejoined to the super-procedure-- 
i.e. satisfying assumptions » and possibly cleaning up— must be taken* 
Outside the turtle world where it may not be so easy to decide if a 
relation is intrinsic, private debugging can still b^ attempted. Just 
as for properties, if the violation does not appear in private, then it 
is knj)wn that it is not intrinsic and the system can. look for causes in 
preceding code. 

4.4.2 Linear Debug ging of Relations ' 

Linear Debugging is a technique for limiting the possible 
repair-points for correcti!ig violated relations "of both the intrinsic 
and extrinsic kind. It is based upon the assumption that DEBUG has 
already privately repaired the main-steps to satisfy their properties. 
The linear debugging technique is to consider editing corrections only 
at preparatory-steps and not internal to the code for the main-steps. 
Main-steps are treated as inviolate black-boxes: their contents need 
I neither be known nor changed. This is based upon the assumption that 
the main-steps are independent and that the only corrections necessary 
to repair reliations is to make adjustments at interfaces. This was the 
' technique used to debug (BELOW LEGS ARHS)* DEBUG limited the search for 
the proper edit by not considering the addition of a rotation to the 
interior of the VEE sub-procedure. Instead, it restricted itself to an 
analysis of possible corrections at the level of the NAPOLEON super- 
procedure. 

Linear debugging fails when the underlying cause of the 
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Violation is due to the code for one of the ptrts* In such a case, it 
is necessary to remove the restriction against modifying Main-^slteps* An 
example where this occurs was shovm in figure 1*9« The violation of the 
mouth not being Inside the head is caused by the size of the Mouth, hot 
by the interface. 

4_.5 IMPERATIVE KNOWLEDGE I 

How is^ the set of possible edits for repairing a violation 
generated? The answer lies in the use of procedural knowledge 
associated with the model primitives which provides direction oh how to 
make the predicate true. The system has imperative knowledge for 
logical primitives like equality and conjunction as well as for 
geometric primitives appropriate to the turtle world. This imperative 
knowledge outputs a set of possible edits whose effect Is tq eliminate 
the violation* * ^ 

In the NAPOLEON example, (NOT (EQUITRI TRICORN}) Is a violation 
of , a user-model. Such violations are fixed by recursive entry to the 
debugger and analyzing the code for the model in private* Such 
recursion ultimately^ reduces the debugging to fixing violations of model 
primitives. 

4.5.1 Imperative Knowledge for Geometric PclSitives 

The following discussion describes in a simplified way the 

imperative knowledge associated with several of the liodel primitives. 

Let X and Y be vectfors and assume that X is accomplished before Y. 

(LINE X Y) <«> (AND^PARALLEL X V) '(CONNOTED X Y)) 

The imperative semantics for AND directs debug to establish the two 
relations of PARALLEL and CONNECTED^ These are defined below. 



Goldstein 



44 • 

* 



Debugging 



(PARALLEL X Y) <«> (« (DIRECTION A) (DIRECTION B),(MOD 180)) 

The annotator records the DIRECTION^of vectors. The repair is to 
insert rotation^ between the code for X and the code for Y so that 
the direction of Y becomes equal to the direction of X (mod IBO)* 

(VERTICAL X) <«> (OR (« (DIRECTION X) 0) (« (DIRECTION X) 180)) 

Alteiv preceding rotations so as to make the direction of X 0 or 180. 

(CONNECTED X Y) , 

Choose a connection point on X (PI) and a connection point on Y 
{PZ). The connection point is sometimes specified in the model: for 
example, the user may have indicated that it should occur (AT 
(MIDDLE (SIDE •*.))). Then compute the vector V from PI to P2. The 
edit is to add code for V into an interface between X and Y« This 
will have the effect of translating Y so that PI is moved to 
coincide with P2. ^ 

If the exact position Is unknown, deduce it from constraints such as 
preferring to effect the code in minimal ways* This is done by 
manipulating individually the length and angle inputs to translation 
and rotation interface steps (occurring between the code for X and 
the code for Y) and observing if X and Y intersect as a result 
Branch in considering alternative allowable connection positions, 

(ABOVE X Y) - (similar technique for BELOW, RIGHT-OF, L^FT-OF) 

To compute the required correction for a given intcy^face: assume 
that the figure has already been debugged to be topologically 
correct--e.g. all of the connections arc correct. This impj.ies that 
the only degree of freedom in interfaces is the heading. \ 

In considering a given interface, find the range of headings which 
satisfy the predicate. The range is determined by first finding the 
heading of most restrictive meaning of ABOVE CENTERED-ABOVE 
wherein* the center of gravity of X is directly above Y. Then relax 
this heading to find the maximum range in which less restrictive / 
meanings of the predicate— COMPLETELY -ABOVE and PARTLY-ABOVE—rem^in 
true. To select a specific heading to actually edit into the codii, 
choose the value that satisfies Hhe most restrictive meaning of \ 
ABOVE, If there is still a range of possible headings, use the 
average value. Record the range considered in case later debugging 
results in conflicts and another heading must be chosen. 



4^*5.2 The Rigid Body Theorem 

Fixed-instruction turtle programs draw rigid bodies^ l,e, the 
only effect of the initial runtime environment is to alter the 
visibility^ origin or orientation of the frame of reference. This 
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theorem simplifies the generation of possible repair edits by allowing 
computation of the requyed rotation for HORIZONTALt VERTiCAL and 
PARALLEL to be ilfOTon^y once, independently of the point in the ccftle at 
which the edit is to be added. Tills is useful since there are usually 
many points at which patching the code must be considered to fix these 
violations* 

For example, suppose the side of a triangle is to be made 
horizbtital. The required rotation is computed for the side. However, 
if the edit is made immediately prior to the code for the side, the 
triangle shape will be destroyed. We rotation, however, can be added 
to preceding code, rotating all subsequent vectors the same amount and 
consequently still making the side^orizontal. 

In general, if the correction is a rotation of the frame of 
reference, the edit can be added anywhere prior to the code group "to be 
rotated. If the rotation Is to change tJe relation between two sub- 
pictures, then it can often occur anywhere in the code occur ing between 
the main-steps which accomplish the sub-pictures. 

4.5.3 Imperative Knowledge of Logtical PrwUcates 

The general advice for fixing (« (P A),(P B)) is to use the 
imperative semantics for property P to either nake (P A) equal to (P B) 
or vice versa. For the simple case of fixed- instruction turtle 
programs, the change Is usually made to A or B on the basis of which * 
occurs last. This is preferred because of the ^gid body nature of sub- 
pictures. For example, suppose A occurs before B. Then adding RIGHT 
:ANGLE before A rotates A but it also rotates B. An opposite rotation 
must be added after A if B is not to be affected by the first edit. 
Thus» fixing the sub-picture which occurs first commits the system to 
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two changes of the program. Of course, editing the code before B mey 

also require a cleai^up because of bad side effects bjMt this is not 

inevitable as it is in the first case. This preference is reflected in 

the general debugging criteria of avoiding conflicts, nlninizing change 

to the user's program and q^ref erring beneficial side effects. 

Thus, fixing equality consists of: 

General ICnowledge: Either A or B can be fixed. Prefer to alter the 
unprotected element (section 4.6) • 

j)^|ixii«- Dependent ICnowledge: Imperative* semantics art provided for 
. relating primitives to their effects. These semantics are used by 
the :annotator to document the effect of a statement of code, and by 
the debugger to add the correct code to achieve a desired effect. 
For example, to alter the direction of a vector, the annotation 
semantics for FORWARD (section Z.Z) indicate that the DIRECTION 
property of vectors is equaHto the current heading. The annotation 
semantics for RIGHT indicate that :HEADING is incremented by :ANaLE 
following execution of "BRIGHT :ANGLE"» The conclusion drawn by the 
debugger, then, is that either "RIGHT :ANGLE" is needed to fix the . 
direction of B or "RIGHT «:ANGIE" it needed to fix the direction of 
A, where :ANGLE equals the difference between the desired direction 
and the actual direction. 

To fix (AND CI C2 correct all of the conjuncts. Order the 

debugging attack on the basis of the same criteria used to order the 
initial set of violations. Correct> properties of main«»steps before 
correcting* relations between main^steps. Correct intrinsic, before 
extrinic predicates. Debug a given group of conjuncts at the same level 
(with respect to the preceding criteria) in temporal order. 

See [Goldstein 1974] for a description of imperative semantics 
for other model primitives si^ch as INSIDE, OUTSIDE, OVERLAP, OR, NdT'and 
FOR-ALL. 



4.6 ASSUMPTION AND PROTECTI ON 

DEBUG generates assumption and protection commentary associated 
with each repair to aid in resolving difficulties where an edit causes 
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new violations or undoes the effects of sone previous edit. AssumpVloni 

about the entry state at the repair-point describe expectations on whi^ 

the imperative seouintics based their analysis. T»ate ction . cdmnen^tary 

guards the co$le fron the repair-point to the Mnifestation-point (the 

place in the cod t at which the sub-pictures referred to by the violated 

model predicate were completed), again because the details of the repair 

depend upon the state nanipulations of the code between the edit and the 

manifestation'-point* Protection is introduced by SussMn in the context 

of debugging blocks world prograns [Susswan 1973J. 

A simple exampliB arises for the followiiTg tree program: 

MODEL TREE ;See figure'4.1. 

Ml PARTS TOP trunk: 
M2 LINE TRUNK 
M3 EQUITRI TOP 
M4 VERTICAL TRUNK 

M5 COMPLETELY-BELOW TRUNK TOP « y " 

M6 CONNECTED TOP TRUNK 

M7 HORIZONTAL (BOTTOM (SIDE TOP)) 

END 



<- (accomplish tree) 

<- (accomplish top) 

<- (setuQ heading such-that 

(overlap (interface statement 30) (side 3 top))) 
<- (retrac« (side 3 top)) 
<- (setup heading for trunk) 
<- (accomplish trunk) 



<- (accomplish equitri) 
<- (accomplish (side 1 triangle)) 
<- (accomplish (rotation 1 triangle)) 
<-' (accomplish (side 2 triangle)) 
<- (accomplish (rotation 2 triangle)) 
<- (accomplish (side 3 triangle)) 

(cleanup position) 
<- (accomplish (rotation 3 triangle)) 

(cleanup heading) 



See figure 4.2 for the picture drawn by TREE4 with the turtle starting 



TO TREE4 
10 TRiANGLE 
20 RIGHT 60 

30 FORWARD 50 
40 RIGHT 45 
50 FORWARD 100 
END 

TO TRIANGLE 
10 FORWARD 100 
20 RIGHT 120 
30 FORWARD 100 
» 40 RIGHT 120 
50 FORWARD 100 

60 RIGHT 120 



at the center of the screen and w£th a heading of zero degrees. 
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- Intended TREE 
FIGURE 4.1 




TREE 4 
VERSION 2 . 
Base Made Horizontal 

FIGURE 4.3 



IX 

t 

TREE 4 
VERSION 1 
Slanted Base and Trunk 

FIGURE 4.2 




TREE 4 
VERSION 3 
Trunk Hade Vertical 

FIGURE 4.4 
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Debuoglng the base of the TOP to be horizontil results in the 
- addition of statement 5 to rotate the triangle so that HJ|{e necessary 
orientation is established. This produces figure 4.3. 

5 RIGHT 30 <- (setup heading such^that (horizontal (side 3 top))) 
Debugging the TRUNK to be vertical by Modifying the initial setup, 
however, undoes this correqtion (figure 4.4). 

p RIGHT 45 <- (setup heading such-that (vertical trunk)) 
The solution is for the initial correction of (HORIZONTAL (SIDE 3 TOP)) 
to include commentary explaining its purpose, scope and assumptions. 
Specifically, this commentary is: 

1. an assumption that the iuUtry^ state to statement 5 is :HEADINGsO: 

(ASSUME (TREE4 STATEMENT 5) (« :HEADING 0)). 

2. a protection to any modifications of :HEADING from statement 5, the 
repair-point, to statement 50 of TRIANGLE, the manifestation-point 
of the errior: . = 

(PROTECT .-HEADING UNTIL (TRIANGLE STATEMENT 50)). 
Statement 50 is the manifestation-point of the error since it 
accomplishes (side 3) and INTERPRET is then able to recognize that 
a violation exists-^the base of the triangle is not horizontal. 

These comments force the debugger to prefer the alternative repair 

strategy of malting the trunk ver^icfl by editing the rotation of 

statement 40 to be RIGHT 90. 

\ A second use of this comm'entary, in addition to preventing 

conflicts between 6dits, is to simplify debugging the procedure if it is 

ever run in a new environment. Unsatisfactory initial state values are 

immediately noticed by the assumption commentary. For example, ii^ 

statement 5 of TREE4 contains the assumption that the entry heading 

should be 0, then being run in any other environment will generate a 

violation. This violation then directs the debugging. 

Thus, previous debugging sessions produce connentSlry whose 
specificity eliminates complex questions of responsibility and 
interpretion. The system has, in effect, generated the 
snapshots of performance which Naur and Floyd utilize to verify * 
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prograns [Floyd 1967, N«ur 1967]. 
The assumption cotment is passed to the debugger as an instruction and 
the result is that code is added prior to stateaent S which converts the 
heading to the desired value* 

Often « protection conflict can be resolved. The debugger is 
simply recalled to achieve the edit which gave rise to the protection, 
taking into consideration the new entry or exit state requireiients. 
This second call to the debugger involves less effort than the first. 
The commentary fron the first renains and indicates the desired 
Cartesian state to be achieved at the Minifestation-point. If the 
second edit succeeds without causing unfixable violations as side 
effects^ then th% systea has patched its own edit and need not reject 
the basic font of its current, analysis. 

A.7 MCipiNq BETWEEN ALT|RNimVl DEBUGGING STRAIi?IES 

More than one debugging strategy is usually available to fix a 

a 

given violation. The strategies differ with respect to their estimate 
of the failure point and with respect to the type of correction they 
apply to fix a given model violation. For example, the imperative 
semiTntics for BELOW indicate the desired direction but allow the 
correction to be added into any prior interface. In NAPOLEON, tile arms 
can be made above the legs by adding the appropriate rotation to the 
beginning of the NAPOLEON procedure or Immediately following statement 
10, the code for the LEGS. The preferred debugging strategy is the one 
that does minimal violence to the user's code, reflects the abstract 
plan, and fixes the greatest number of violations. 
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4.7.1 Plausibility; on the Bisis ^ Sidt Ef fects 

The first criterion for Judging the success of a partial 
debugging strategy is an analysis of the side "effects of the 
corrections. The debugging strategy with maxiMl beneficial side 
effects is preferred. Beneficial side effects occur by eliMinating 

additional model violations, satisfying planning expectations or * 

* ■ 

tliminating violations of rational Torn, 

One might ask why an edit might have any beneficial side effects 
at all. Isn't it more likely to have bad side effects and cause 
other violations? The answer is that often several violations 
are caused by the same error in the code. Then one debugging 
strategy will stand out from its brethren by fixing this error 
and thereby simultaneously curing several violations. " 

On the other hand, sometimes a correction causes additional 

model violations. In this case, either thf new violations can 

themselves be debugged or the debugging strategy must be abandoned. 

Assumption and protection commentary are used to Help in understanding 

those bad side effects wherein one edit undoes the effect of some other 

debugging edit. If the bad side effect cannot be eliminated, then the 

debugging strategy must be rejected. This is the case With a linear 

debugging of GOOGLV.EVES (figure 4.5). 

The oyes cannot be brought into the head by shrinking the interface 

without causing them to overlap the nose. Thus this debugging strategy 

eliminates one violation (OVERLAP EYE HEAD) only to introduce another 

(OVERLAP EYE MOSE). The. system is forced to consider non-linear 

debugging and fix the parts themselves. 

4.7.2 Plausibility on tjie Basis of Minimal Change 

Another plausibility-criterion is that of minimal change to the 
user's code. A debugging strategy that changes ^an input is preferred to 
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GOOGLY EYES 
FIGURE 4.5 




one that adds stattaents; and a strattgy that adds stattntnts is in tiirn 

f -v. 

preferred to one that dtlttts thin. The rationale is that a repairman 
should make minimal changes to a system. The goal is to fix the program 
in harmony with the user's intent^, not to redesign it. This caution is 
further Justified by the fact that the system does not fully know the 
programmer's intent or plan* Hence» it must be hesitant to make major 
revisions to his program. 
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4.7;3 P^usibility on the Basis of Caveat CoMMents 

A third basis for choosing between alternative debugging 
strategies is advice froH the annotator and plan-finder on likely 
errors. The annotator alerts the debugger to oddities in prograa 
Structure which My be the underlying cause of sorn seaantic violation 
(section 2.4). The plan-finder fulfills the saM purpose with respect , 
to code that contradicts expectations arising fro* the type of plan. 
Tjie^echanism of infomlng the debugger of the possibly erroneous code 
is through "caveat" coMents. The coMents are noticed when the 
debugger consldieFs' the associated code in the cours^of debugging some 
model violation. A repair edit is accorded extra plausibility by thf , 
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debugger if the correction eliminates the complaint that initiated the 
caveat;* • ^ 

Caveats generated by the plan-fiijfder are created by noting 
insertions which are not transparent, interrupted"-steps which depend on 
specific runtime environments and linear plans in which main^steps use 
the same resource such as an assumptiof^^out a particular estate 
variable. In an extended system, caveats would be generated by such / 
oddities as iterative programs which fail to halt and shared free " 
variables. As an example, recall that the arms in NAPOLEON represetited 
a non- transparent inserjt and that ^this information advised the debugger 
to edit the correction into VEJE rather than directly into the NAPOLEON 
super**procedure « 

Comments are used-^rather than the Annotator or Plan^Finder 
immediately calling the Debugger to correct the vlolation-*-because a 
Violation of rational form is not a guaratr^ee of a bug: the oddity may 
be harmless or even intended^by the programmer. An example in which a 
sequence of FORWARD instructions arises naturally i$ the following ^ 
triangle program: / 

TO TRI . ' 

10 FORWARD 50 . 

20 FORWARD 50 ' 

30 RIGHT 120 

40 FORWARD 100 

50 RIGHT 120 

60 FORWARD 100 . t.. 

The first two FORWARD'S- are surprising. However, If this TRI is being 
debugged in preparation for being converted to' a triangular head with, 
the remainder of the stick-man inserted as statement 15, then the 
apparent violation of rational form is explained. The utility of 
comments is that if the code 1$ not suspected of being in error by the 
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debugger, the comment has no effect. It plays a role only if DEBUG 
finds a model violation that can possibly be corrected by. changing the 
odd code. Only then does the comnent enter into the analysis by 
supporting such adding plausibility to debugging strategies that 
eliminate it3 complaint of non-transparent insert or sequential 
commands* ^ t 

4,7>4 Guessing the Culpable Interfa ce . * 

Even with the restriction to linear edits, fixing a predicate 
relating two main-steps may produce many possible edits. For example, 
making the head above the legs in NAPOLEON could be done by"" adding a 
rotation at any of several places in the program preceding the execution 
of the TRICORN sub-procedure. Consequently^ the system initially 
considers edits to only two interfaces — the interface immediately 
preceding the second m&in^step (i«e«.co(i^ for the model part 
accomplished last) |it|i5t the initial setup to the program. The- immediate 
interface is preferi^ qn'the expectation that preceding interfaces have 
already been protected in the course of debugging. ' The global setup is 
considered because "Unexpected Runtime Environment'* Is a common cause of 
errors. The plausibiiity of these editing points Is then aiM^yzed hyi 
the criteritkgtjtesciribed in th^ preceding sections beneficial side 
effects, minimal change, and caveats as well as the protection criteria 
described in the preceding Section. If they are found implausible, ^ 
additional interfaces are considered in order, proceeding backwards from 
the second main-step. 
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SUHMAmr Of DEBUGGING COMCEPTS !^ 

The debugger's knowledge^d^vides into two c«tegories: general 
debugging technique and specififiBperative knowledge of logic and 
geometry. • 

Debugging Technique 

1. Linear Attack First verify main-step* privately. Then analyze 
relations in terms of interfaces. Only If all else fails, modify 
main-steps to fix relations. 

^. Plausible Search— Compare alternative debugging strategies using' 
plausiblity criteria of minimal change to the user's code and 
maximal beneficial side effects. 

3. Culpable Interfaces — Prefer either the initial interface or the 
interface immediately preceding the bugged module. This is based 
on the assumption that the temporal attack has already verified 
intermediate interfaces. 

4. Caveats — Use caveat comments generated by the Plan-Finder and 
Annotator to suggest the location of the repair. 

5. Intrinsic versus Extrinsic Errors Classify model violations as 
intrinsic or extrinsic on the basis of whether the error is 
internal to the code being examined. Intrinsic errors have limited 
scope and can be debugged iprivately. 

6. Handling Multiple Bugs debug those violations of most-limited 
scope first: that is, debug properties before relations; then 
intrinsic predicates before extrinsic ones, and finally in temporal 
order. , 

7. Com*en.tary — Use commentary to express the purpose, assumptions 
and scope (protection) of a correction and to notice conflicts 

. between different corrections. 

Knowledge of Geometry and Logic ' 

1. Imperative Semantics of predicates - In addition to standard 
verification code, primitives hav# j^emantics that suggest what to ^ 
do to make the predicate come true. Tf^tfsiconsists of procedural 
knowledge which examines code and generites .edits to male a 
particular geometric predicate true. 

2. Rigid Body Theorem - This theorem is a precise statement of the 
effect of the initial environment on a segment of code for Fixed- 
Instruction Turtle Programs, namely that the code produces a rigid 
body and that the initial environment affects only the orientation 
and position. 
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3. Imperative Knowledge for Logical Predicates - Procedures for naking 
conjunction, disjunction, negation, equality and set nember ship ^ 
true with mininal effort. 



4>9 Class if icatf ion of Bujjs 

The following taxonomy of bugs suMarizes the types of errors 
which "the system corrects* \ 

Linear Nain-*Step Failure: 

Manifestation: Failure of main-step to accomplish model ' 

part in private, i.e. vrtien run independently. ^ 
Fix: (Private Debugging) Repair in private, rejoin and , 

satisfy any initial assumptions. 
Ex: (NOT (EQUITRI TRICORN)) in WAPOLEON. 

Preparation Error: 

Manifestation: Violation of relation betif^bn model parts « 
Fix: (Linear Debugging) Find culpable interface, make 

edit suggested by the imperative for the 

predicate, and protect ai^sumption^ until 

the point at which the error was manifest. 
Ex: See Unexpected Runtime Environment and Local ' 

Preparation Errors 

Unexpected Runtime Environment; (type of preparation failure) 
Manifestation: Violation due to false assumptions of 

the entry state^to program^ (Program does succeed in 
certain environments). 
Fix: Add an initial setup i^ich converts the actual entry 

state to the desired entry state. 
Ex; (NOT (BELOW LEGS ARMS)) in NAPOLEON. 

' ■ . \ . ' ' * ^ 

Local Preparation Error: (type of preparation error) 
Manifestation: Violation intrinsic to the program, 
and not dependent on the initial environment. 
Fix: Modify state appropriate to the imperative semantics 

for the violated predicate* 
Ex: (NOT (VERTICAL TRUNK)) dn TREE4* 

Non-*Linear Main-Step Failure: 

Manifestation: Main^step succeeds in private. 
Fix: See resource conflicts, insertion errors, 
and global errors described below. 
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Unconsidered Second-Order Constraint on Nain-step: ^ i 

(type of non-linear main-step failure) 

Manifestation: Violation of a property of aodel part 
not detected in private. Manifested by Analysis 
of a relation between the main-step and some 
other model part. 

Fix: Modify main-step in such a way that violation is 

corrected vrtiile the first-order description of properties 
asserted in the model is still satisfied. Guidance is ' 
provided by the imperative semantics for the predicate. 
Examples of such transformations are dilation and 
reflection. / 

Ex: (NOT (INSIDE MOUTH HEAD)) in BIG.MOUTH. 

Resource Conflict: (type of non-linear main-step failure) 

(Mentioned for completeness: not handled by debugger.) 

Manifestation: Violation of property of part 

described in model which was not exhibited in private. 

Fix: Some assumption made when run privately is being 

violated in public. Such an assumption could be the 
availability of a given resource, e.g. « free variable. 

Ex: Attempt to correct both (VERTICAL BODY) and 

(HORIZONTAL (SIDE TOP)) in TREE4 by modifying the 

initial interface statement 5 (section 4.6) , 

Insertion Error: (type of non-linear main-step failure) 

Manife^station: Main-step failure not indicated in private 
with the additional element that a caveat cotmnent 
generated by. the plan-finder informs the debugger 
that the code group for the main-step surrounds an 
insert which is not transparent. 
Fix: Make insert state-transparent. „ 
Ex: (NOT (LINE BODY)) in NAPOLEON. 

Global Error: 

Manifestation: Model part accomplished non-locally fails. 

Fix: Find relevant theorem which was the basis of expecting 
the global plan to succeed. Find' assumptions made by 
theorem which were not justified. Make these assumptions 
true. 

Exi, (NOT (LINE (SIDE 1 TRICORN))) in NAPOLEON. 
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5. CONCLUSIONS 

5..V TOP-LEVEL DEBUGGING GUIDANCE 

Tht top-level organization of Modil-driven debunging is to order 
the model yiol«tlons and then proceed to fix thea in turn. This 
. technique makes the basic assumption that guidance in fixing the program 
can be obtained by analyzing the specific details wherein the picture 
failed to satisfy its description. Alternatively, top-level guidance 
can be obtained through: 

1- 5*ru^cture-dr^^^ debugging - insight into the form of programs; 
e.g. such structural considerations as recursive and iterative 
control patterns and global versus local variable scope. 

2' eyolution-driven debugging - the evolutionary or editing history 
of the user's code. 

-3. RCfiCMI-dr^^n debugging - the abstract form o^the process at 
the time of the error [Sussman 1973]. 

A more complete debugging system would exhibit all of these forms of 

direction. 

SjJ GENERALIZABILITY OF DEBUGGING TECHNIQUES 

The mini-world of prqgraas against ijfhich this analysis of 
debugging is tested is that of fixed-instruction turtle procedures. 
These are, of course, a particularly simple form of program. Thtfir 
simplicity allows the imperative semantics for the geometric pi'imitives 
to utilize the Rigid Body Theorem, Justifying the same state change to 
different interfaces to correct a given bug. 

The debugging techniques used to handle even these simple 
programs are by no means exhaustive. Nevertheless, it is worth noting 
that many of the techniques utilized by the model-driven debugger are of 
broad application: an initially linear analysis, the need to order the 
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attack on multiplt bugs, coMptttnct to eop« with altarnative dtbuglSring 
strategles--th9se are useful regardless of the nature of the top-lavel 
direction or the complexity of the prograa. 

, The thoice of plane geo«etry as the seisantic dooain for MYCROFT 
was not accidental. Geometry allows the use of a Cartesian annotator 
and a powerful model language for specifying spatial relations. Other 
domains may not be susceptible to a NYCROFT-likt approach because of the 
lack of powerful ways in which to document the effects of the program 
and the lack of a good model language. However, it is worth noting two 
points: 

1. spatial models are very important for programming m 

applications beyond graphics. (This is reflected in the way 
prograimners refer to memory, stacks and data structures in 
spatial ways. ) 

and 2. program planning and debugging involve techniques of broad 
applicability but cannot be entirely done in the absence of 
domain-dependent knowledge. 

t . 

5.3 EXTENSIONS 

The design of MYCROFT required an investigation of fundamental 
problem solving issues including description, simplification, linearity, 
planning, debugging and annotation. MYCROFT, however; is only a first 
step in understanding these ideas. Further investigation of more 
complex programs, and of the semantics of different problem domains is 
^necessary. It Is also essential to analyze additional planning concepts 
such as ordering^ repetition and recursion as well as the corresponding 
debugging techniques. Ultimately, such research will surely clarify the 
learning process in both men and machines by providing an' understanding 
of how they^ correct their own procedures. 



Gl 



Goldstvin 



Bibliography 



6. BIBLIOGRAPHY ^ 

LAbtlson 1973] ^ 
Abelson, GoodMn, N. and Rudolph, I. 
LOGO manual . 

LOGO Memo 7 LOGO Projtct, HIT AI Laboratory (August 1973) 

tFloy(f'l967] ; 
Floyd, R. W. 

"Assigning Meaning to Programs" 
Proc. Symp App. Hath AHS vol. XIX (1967) ' 

LFahldan 1973 J 
Fahlman, Scott 

A Planning System For Robot Construction Tasks 
AI-tR-283 MIT AI Laboratory (Hay 1973) 

- LGoldstein 19743 
Goldstein, I., 

Understanding Simplff Picture Programs 
AI~TR-Z94 MIT AI Laboratory (Harch 1974) 

[Hewitt 197U 
Hewitt, C. 

"Procedural Embedding of Knowledge in PLANNER" 
Prbc. IJCAI 2 (Sept 1971) 

[McDermott 19723 
HcCermott, D.V. and G.J. Sussman 
The CpNNIVER Reference Hanual 
AI Memo 259 MIT AI Laboratory (July 1973) 

I Naur 19673 
^Naur, P. 

"Proof of Algorithms by General Snapshots" 

BIT 6, 1967, 310-316. 

LPapert 19713 * 
Papert, Seymour A. 

"Twenty Things to Do with a Computer" 
AI Memo 248, HIT AI Laboratory (June 1971) 

I " 

LPapert 19723 ^ 
Papert, Seymour A. f 
"Teaching Children Thinking" 
Programmed Learning and Educational Technology, Vol.9, No. 5 (Sept 1972) 

(.Sussman 1970] 

Sussman, G.J., T. Uinograd, and E. Charniak . ^ 

Micro-Planner Referen ce tUnual 

AI Memo 203, HlT AI Laboratory (December 1971) 



V 



erJc • 



Goldst«iiL 



0^ 



iibllographst. 



[SussMn 1073] 

SussMn, O.J. ^ 

A ^put§tion«l noM of Skill Acquisition 

AI-?rR-297 MIT Al Ubor«tory (Stpt 1970) 

LWinston 1970 J , 
Winston^ P.H. *" 

Learning Structural Dascriptions froa Ex— pla« 
HAC-fR-7e MIT AI Laboratory (8«pt 1970) 



t 



68 



